The brokering of goods and services is a time-honored technique of facilitating commerce. In its many forms, such brokering shares a recognition that providers of goods and services are often unwilling or unable to undertake the effort needed to initiate, conduct, or consummate a transaction with one or more consumers. For example, a manufacturer of a good may prefer to focus on the manufacturing process, and may therefore contract with a broker, who may then be responsible for locating a purchaser of the manufactured good and for conducting and consummating the sale of the good with the purchaser. Of course, the broker typically receives a share of the purchase price or some other fee or payment for providing these brokering services. In this way, the manufacturer (or other provider) and the broker may concentrate on developing their respective areas of expertise.
In the computer, network, and software realm(s), brokers have adopted these general concepts for the delivery of goods and services, e.g., over the Internet. For example, brokers may provide a marketplace in which various providers may sell their respective goods and/or services. For example, a provider of a ‘real-world’ item such as a book (e.g., a publisher) may utilize a broker to sell copies of the book. Similarly, brokers may exist which facilitate sales of digital content (e.g., songs or movies) and/or sales of software applications, among many other items for sale.
Meanwhile, however, software has evolved from stand-alone, integrated, monolithic applications into discrete services which provide specific functionality (or which combine to provide desired functionality), often on an as-needed basis. The providing of software in this and related form(s) is often referred to as “software as a service (SaaS)” and/or as a “service oriented architecture (SOA).” For example, a service for providing seat reservations may be provided, e.g., to an airline for booking airplane seats, or to a theater for booking concert seats. Conceptually, virtually any software functionality may be provided as a service, e.g., over the Internet or other network.
In theory, the intersection of brokering and software services, then, is conceptually straight-forward. That is, software service providers (referred to herein as service providers) may be as desirous as any other provider to obtain the advantages of providing their (software) services through a broker. In some cases, such as when software is conceptually similar to discrete goods (as in the example(s) above of digital songs or movies), the implementation of brokering services is also straight-forward. Specifically, for example, a broker may obtain rights to sell the software in question, and may locate a customer for the software and otherwise conduct and consummate the sale.
In practice, however, many services are conventionally difficult or impossible to broker, at least in any standard or widely-applicable manner. For example, there may be a software service provided by a municipality or other governmental entity to potential small business owners for initiating and registering a business license of some kind. These and other similar services may be complex, long-running process(es) which execute over the course of multiple days or longer. In addition, such multi-step services may execute on back-end (e.g., legacy) applications of the service provider and may require multiple interactions/interfaces with the service provider and/or other stakeholders.
In these situations, it may be difficult for the service providers to supplement their services to make them commercially viable, or to otherwise provide their services to consumers. For example, the service provider may have particular preferences, from a business perspective, about whether, when, and how payment(s) should be received for the service. However, an attempt by the service provider to integrate payment functionality into the service in question may fail outright, or may disrupt the actual functionality of the service. For example, the service provider may wish to obtain partial payments at different points in the process, but may fail to configure a timing of these partial payments correctly with respect to the service as a whole, or may fail to ensure that the full payment is ultimately received (e.g., when the service process/interactions follow an unlikely or unexpected route).
Conversely, a service broker may be an expert at the technical aspects of adding payment functionality to the service, but may not have the specific business knowledge of the service provider with respect to the service in question. Moreover, even if the service broker were to expend the effort to modify the service to incorporate payments or other service delivery functionality, the service broker may not wish to take on the cost or effort needed to provide (e.g., host) the service directly to consumers.
As a result of the above, no satisfactory solution exists for configuring and delivering brokered services in a practical manner that leverages the relative areas of expertise of the involved parties. Consequently, service providers are less able to commercialize their services, service brokers are less capable of brokering such services, and consumers suffer a more-limited market for, and less access to, services that they may wish to use.